くらめその情シス：Azure AD条件付アクセスを全社導入したおはなし
どうも、情シスやってますアノテーションの徳道です。
2020年からPCのMDM管理に絡んで、Azure Active Directory関係の導入事例ブログをくらめその情シスシリーズで書いてきました。
その集大成として2021年の12月にクラスメソッドグループの基幹システムへAzureAD条件付きアクセスを適用し、本番運用を開始しました。
今回は本番に導入した条件の設定の事例を紹介したいと思います。
【これまでの関連ブログはこちら】
条件付アクセスの構成概要
クラスメソッドの条件付きアクセスの状態を図にしてみました（2022年1月現在）。
重要な社内システムについては以下の条件がANDの時にアクセスを許可するようにしています。
- アプリにアサインされたAzureADアカウント
- AzureADアカウントのMFA認証
- 接続デバイスがMDMに参加し、Intuneのセキュリティポリシーに準拠
- ブラックリスト指定の国以外からのアクセス
連絡手段として接続性が重要なチャットサービスは条件を少し緩くします。
- アプリにアサインされたAzureADアカウント
- AzureADアカウントのMFA認証
なぜ条件付きアクセスを導入したのか
クラスメソッドでは比較的早くから自由な働き方、地方でのリモートワークが普通に行われてきました。
これまでの取り組みでPCのデバイス管理はリモートに対応していますが、社内システムのアカウントについてはリモートワークでは十分に安全性が担保されない状態のままで運用してきたことは否めません。
たとえばユーザーID、パスワード、MFAさえそろっていれば、ぶっちゃけ話、個人所有やインターネットカフェの共用パソコンからでも社内システムにログインは可能だったのです。
今後、リモートワークが当たり前になるときに、
- 正しい人
- 正しいデバイス
- 正しい状態
条件付きアクセスを導入した理由はこれらがAND条件でそろった安全な状態で社内システムへアクセスができるようにするためです。
条件付きアクセスを導入し、運用する際の課題とワークアラウンド
これまでの取り組みをまとめると以下の3点になります。
- 会社貸与のPC（Mac、Windows）をMDMでポリシーの一元適用
- 基幹アプリケーションのIdPをAzureADに集約
- AzureADでのMFAを全社必須
これで「AzureADを持つ社員」で「会社貸与PC」は条件付きアクセスを導入することが可能になりました。
しかしどこにでも例外というものは存在するものでして、1割の残タスクを消化するためにそれまでと同じくらいの工数をかけることに…。
その1割の課題とは…
- 個人のモバイルデバイス
- Amazon WorkSpacesなどMDMに参加できない仮想マシン
- メールアドレスだけ貸与しているビジネスパートナー
これらをどのように扱うか、ということでした。
個人のモバイルデバイス
基本的にモバイルデバイスで会社の基幹システム（メールやカレンダー）にアクセスが必要なものはMDMに登録をしてもらい、ポリシーに準拠してもらうことで条件付きアクセスの対象としました。
この整備が一番作業量が多くかなりボリュームがあるので、また別の記事で紹介させていただきます。
最初の構成図にあるように、社員が連絡用として必要になるチャットサービスについてはAzureADでのログイン/MFA設定を必須条件とすることで自由にアクセス可能です。
Amazon WorkSpacesなどMDMに参加できない仮想マシン
こちらはちょっと厄介です。Intuneの設定ができないので、どうしてもAzureAD条件付きアクセスのポリシーに準拠させることができません。
そのため、Amazon WorkSpaces利用者に社内システムのメールやGoogleドライブへのアクセスが必須か、確認したところいずれも代替手段がありました。
ただし、今後社内システムアクセスが必須の方がでてきたときに対応できるように準備はしておくことにしました（後述）。
メールアドレスだけ貸与しているビジネスパートナー
こちらもちょっとこまりました。PCを貸与していないので、こちらもデバイス制御による保証ができません。
これらは社内システムアカウントは貸与しているものの、メールだけ、一部のGoogleドライブだけ、など用途が限定されています。
リスクの範囲を明確にするために以下の対応でデバイス制御なしで条件付アクセスを適用することにしました。
- 対象アカウントをリストアップ、責任者を明確化
- 社内システム側で利用する機能を限定する
これらについては今後、仕組みが整えばできるだけ安全側の対応ができるようにしていくように課題として管理しています。
条件付きアクセス設定
ではいよいよ条件付きアクセスを適用するアプリごとの設定です。
今回は事例としてGoogle Workspaceの設定を紹介します。
Google Workspace用の条件とアクセス許可
クラスメソッド社内のメール、ストレージ、コミュニケーションを集約しているSaaSです。
デバイス制御とMFAによる安全性の確保だけでなく、前述の課題に挙げた例外についてもリスクを受容しつつ対応する必要があります。
- 許可する条件
- AzureADで指定されたユーザーアカウント
- 禁止されている国からのアクセスではないこと
- 指定のOS、アプリ
- AzureADのMFA
- Intuneのコンプライアンスポリシーに準拠
- 例外
- Intune参加できないデバイスからの特定ユーザーアカウントのアクセスを認める （Google側で利用できるアプリケーション、権限を制限）
これを満たすために複数の条件付アクセスを設定しています。
- 条件付きアクセス（デバイスポリシー準拠：バイパスあり）
- 条件付きアクセス（ブラックリスト国アクセスブロック）
- 条件付きアクセス（デバイス除外グループ）
指定以外の項目は「未構成」です。特に指定がない場合は「対象」に設定します。
条件付きアクセス（デバイスポリシー準拠：バイパスあり）
- デバイスプラットフォーム
- iOS
- Android
- Windows
- macOS
- 場所
- アクセス許可国
- クライアントアプリ
- ブラウザー
- モバイルアプリとデスクトップクライアント
- 許可
- 多要素認証を要求する
- デバイスは準拠しているとしてマーク済みである必要があります
- 選択したコントロールすべてが必要
- セッション
- サインインの頻度：7日
条件付きアクセス（ブラックリスト国アクセスブロック）
- 場所
- ブラックリスト国
- クライアントアプリ
- ブラウザー
- モバイルアプリとデスクトップクライアント
条件付きアクセス（デバイス除外グループ）
以下は条件付きアクセス（デバイスポリシー準拠：バイパスあり）と同一設定です
- デバイスプラットフォーム
- 場所
- クライアントアプリ
- セッション
以下のみ異なります。これはIntuneのコンプライアンスポリシーに準拠したデバイスではなくともアクセスを許可するためです。
- 許可
- 多要素認証を要求する
- 選択したコントロールのいずれかが必要
【重要】各条件付きアクセスポリシーのユーザー(グループ)の網羅性に注意
3つの条件を作成し、アプリに割り当てるわけですが、ここで条件を正しく動作させるために重要なのがユーザー（グループ）の指定です。
これは、条件付アクセスポリシーの「対象に割り当てられたユーザー」だけを条件の評価対象にする、ということに起因します。
アプリと条件付アクセスポリシーの割り当てユーザーが同一範囲である
まず、そもそもSSOのエンタープライズアプリ（事例ではGoogleWorkspace）に割り当てるユーザーと条件付アクセスに割り当てるユーザーが同一であることです。
条件付アクセスのほうがユーザーの割り当て範囲が広い場合はあまり問題になりません。
しかしエンタープライズアプリに割り当てたユーザーが条件付アクセスに割り当てられていない場合。
これはそもそも条件付アクセスが評価されません。
イコール、AzureADにログインできれば無制限でアクセスできてしまうのです。
許可・ブロックは別々のポリシーで設定する必要がある
事例の要件には「禁止されている国からのアクセスではないこと」が盛り込まれています。
つまり、ブラックリストの国からのアクセスを「明示的にブロック」する必要があります。
「許可ポリシーの対象外にブラックリスト国を設定すればいいのでは？」と思われる方もいるでしょう。
条件付アクセスのポリシーはあくまで「対象を評価」し、その結果で指定されたコントロールを決定します。
つまり、「許可の対象外＝ブロック」ではなく「条件を評価されない」となってしまうためなのです。
この挙動は見落としがちなところなので注意が必要です。
条件の対象・対象外ユーザーが包括的に網羅されていること
デバイス制御のみ一部のユーザーを対象外にする場合もユーザーの割り当てに注意が必要です。
以下の2つの条件でユーザーが包括的に網羅されるように割り当てをします。
具体的には A、B、C、D、Eのユーザーがいて、BとEがデバイス制御の対象外だった場合
- デバイスポリシー準拠：バイパスあり ＝ 原則のグループ：A、B、D（C、Eは対象外）
- デバイス除外グループ = 例外のグループ：C、E
となるように割り当てをする、ということです。
条件付アクセスが評価する際、対象よりも対象外に指定されているユーザー(グループ）のほうが優先されます。
対象には原則の大きなグループを割り当て、対象外を例外にすることで運用を簡素化することができます。
何らかのマシントラブルで
「リスクを受容してGoogleWorkspaceへのアクセスを許可する」
冒頭で課題としていた
「Amazon WorkSpacesなどMDMに参加できない仮想マシン」
「メールアドレスだけ貸与しているビジネスパートナー」
など例外、緊急対応用のグループも割り当てておきます。
グループ設定のイメージ
- 原則の全体グループ（A、B、C、D、E）
- 例外のグループ（C、E）← 原則のグループから抜く必要はない
- 緊急対応のグループ （A）← Aに問題が生じて緊急で対象外にするような運用を想定
原則のポリシーには、以下のユーザー（グループ）を割当します。
- 対象：原則の全体グループ（MDMに割り当てされている全ユーザー）
- 対象外：例外のグループ
逆に、例外のポリシーには対象に例外のユーザー（グループ）を指定します。
- 対象：例外のグループ
- 対象外：ユーザー、グループは指定しない
どのように運用しているか
条件付アクセスのポリシーをエンタープライズアプリに割り当ててしまえば、ほぼポリシーを操作することはありません。
アクセスの制御はすべてユーザーグループへのユーザの追加/削除でコントロールします。
- 新入社員 → 原則のグループに登録 （条件付アクセスに自動で設定）
- ビジネスパートナー/システムアカウント → 例外のグループA（目的がわかるグループに設定）
- PC不具合等で一時的にパスワード、MFAのみで許可 → 例外のグループB（一時除外専用グループ）
運用上、リスクの発生する２と３については、十分にリスクの確認を行い、責任者の承認（ワークフローで証跡も残します）のうえで例外グループに設定するようにしています。
また、例外グループは定期的に棚卸、チェックを行うことで一時的に例外にしているユーザーが放置されないようにもしています。
さいごに
AzureAD条件付きアクセスを導入することで、以下の3つの状態を担保できるようになりました。
- 正しい人
- 正しいデバイス
- 正しい状態
フルリモートワークでのアクセスの安全性をかなり向上できたのではないかと思います。
100%ではないにしろ、アカウント乗っ取りなどによる不正アクセスについては管理情シスとして安心です。
これからはこうしたクラウドのMDMとIdPが連携したアクセス制御が主流になっていくのではないか、そうなってほしいな、と考えています。
アノテーション株式会社について
アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。 「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。 現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイト をご覧ください。
